Add sensitive exposure split query #207
Conversation
|
Can we rename the |
javascript/frameworks/cap/src/sensitive-exposure/SensitiveExposureHeuristicSource.md
Outdated
Show resolved
Hide resolved
javascript/frameworks/cap/src/sensitive-exposure/SensitiveExposureHeuristicSource.md
Outdated
Show resolved
Hide resolved
javascript/frameworks/cap/src/sensitive-exposure/SensitiveExposureHeuristicSource.ql
Outdated
Show resolved
Hide resolved
| predicate allowImplicitRead(DataFlow::Node node, DataFlow::ContentSet contents) { | ||
| // Assume all properties of a logged object are themselves logged. | ||
| contents = DataFlow::ContentSet::anyProperty() and | ||
| isSink(node) | ||
| } | ||
| } |
There was a problem hiding this comment.
What does this do? What kind of code does this intend to capture?
There was a problem hiding this comment.
its from the out of the box queries, and is very necessary, it means that the definition of a variable being "read" includes any access of its properties (I think at sink locations only, as opposed to overall field sensitivity as an additional flow step would capture)
I dont really see any other form of documentation anywhere talking about this common predicate/to add to the comment but for our own understanding, if you want, searching for "allowImplicitRead" in slack across all channels does find some refs to it and a bit of useful conversation confirming that this is the intended use of that
javascript/frameworks/cap/src/sensitive-exposure/SensitiveExposureHeuristicSource.md
Outdated
Show resolved
Hide resolved
...es/sensitive-exposure/sensitive-exposure-js-all-sinks/sensitive-exposure-heuristic-source.js
Show resolved
Hide resolved
|
Also, please add a description of the relationship of this query to the existing |
What This PR Contributes
js/cap-sensitive-logquery (to avoid duplications) but does use the CAP specific sinks and therefore also avoids duplication of alerts with the out of the box query.Future Works
none at this time